On 17/10/13 00:07, Phillip Hallam-Baker wrote:
Each HSM vendor has their own security controls but a FIPS140 level 4
device won't release them except to another FIPS-140 device. There is no
way to extract the key from the system unencrypted.
Phil: what prevents a government just turning up
On 11/12/13 14:31, Kathleen Wilson wrote:
There are a few cases where customers are asking CAs for more time to
transition off of their 1024-bit certificates.
What exactly are CAs asking for? Are they asking for permission to
continue issuing such certs? Or are they asking for permission to not
On 10/12/13 06:20, Jan Schejbal wrote:
The third sub-ca cert (Subject AC DGTPE Signature Authentification)
includes a CRL DP for a CRL issued by sub-ca 2, validity 2011-09-09 to
2014-09-13. The CRL is empty.
Look again. It seems that it now contains 1106 certificates (!), with
widely varying
On 29/01/14 05:08, Brian Smith wrote:
Benefits of my counter-proposal:
1. Fewer roots for us to manage.
Only for a very narrow definition of the word root. There's the same
number of embedded trust anchor points.
3. Because of #1, there is potential for us to design a simpler root
On 13/03/14 19:20, Rick Andrews wrote:
Since support for CRLs has been removed from Firefox, why does
Mozilla's root policy
(http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/)
require CAs to maintain and publish CRLs?
Is it because Mozilla
On 29/04/14 00:16, Kathleen Wilson wrote:
My personal opinion…
And mine:
Free-at-the-point-of-issuance certs have been a great thing for the
Internet, and I would be very sad to see them go away. I also think in
general that the charging structures of (non-insurance :-) business
models are best
On 28/04/14 20:04, Kathleen Wilson wrote:
Please respond with one of the following:
A) Mozilla’s spreadsheet of included root certificates has the correct
link to our most recent audit statement, and the audit statement date is
correct.
B) Here is the most recent audit statement for our
On 29/04/14 15:31, Jan Lühr wrote:
I'd like to live in a world, were revocation is without any hassle an
Community Driven CAs like CAcert are providing security for sites to be
interested in.
That sounds to me like: I'd like to live in a world where whatever
costs there are for having a
On 30/04/14 00:24, Kathleen Wilson wrote:
On 4/29/14, 3:44 AM, Gervase Markham wrote:
Does the list on that wiki page need to include the Microsoft equivalent
of the SGC EKU? Or are we not mentioning that?
Yes, it's item #1 in the Things for CAs to Fix section.
Item #1 refers to Netscape
On 01/05/14 17:55, Kathleen Wilson wrote:
Do we need to _stop_ people using this OID, or is it sufficient to
merely start to require that people use the correct one (Server Auth)?
We want people to stop using the obsolete Netscape SGC OID.
Why is it not sufficient to require people to use
On 09/05/14 01:13, Brian Smith wrote:
We can *try* doing it for *end-entity* certificates. However:
All good points. And I think doing it for EE certs gives us the safety
we require. So let's not try for intermediates.
Gerv
___
dev-security-policy
On 13/05/14 14:48, Peter Bowen wrote:
I would add the old Netscape Step-Up/SGC (2.16.840.1.113730.4.1) and
any EKU (2.5.29.37.0) to the list as well.
The point of the bug I reference is that we'd like to stop caring about
these (in code), because allowing anyEKU means that we include in scope
On 05/06/14 19:39, David E. Ross wrote:
Does NSS use any code in common with OpenSSL?
Not to my knowledge, but others are far more expert than me.
Is any part of OpenSSL
used in any Mozilla applications?
Firefox OS ships (or used to ship) OpenSSL as part of its wifi stack.
And of course
On 21/06/14 17:15, Kurt Roeckx wrote:
There are still a few new certificates generated with 1024 bits.
I've been filing bugs about those and there were only a few so
far this month.
Thank you for doing this work; it really is appreciated.
Gerv
On 23/07/14 10:06, nick.l...@lugatech.com wrote:
The status quo today means that it is not possible to discriminate
programatically between a DV and OV certificate in a standardized,
reliable way.
This is because Mozilla's position is that, in security terms, there is
no relevant difference.
I am generally in favour of this plan - I think it's the right way to
go. I am not sure we will ever get to hard-fail for plain OCSP, but I am
very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote:
There's one major open issue
On 02/08/14 15:20, Jesper Kristensen wrote:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
There is a proposed standard for multi-stapling but as far as I remember
it's not even finished yet, yet alone implemented and deployed. We
decided that we
On 04/08/14 18:16, Erwann Abalea wrote:
I imagine you have access to more detailed information (OCSP URL,
date/time, user location, ...), could some of it be open?
Not necessarily; I suspect this data was gathered using Firefox
Telemetry, where we try very hard to avoid violating a user's
On 11/08/14 04:16, David E. Ross wrote:
Rosenthal is also a reseller of X.509 subscriber certificates, which
should mean he understands Internet security. Otherwise, how is he
allowed to sell such certificates?
I don't often say this, because it's not often true, but...
LOL.
Gerv
Short-lived certs are one plank of our future revocation strategy.[0]
Currently, it is not permitted by the CAB Forum Baseline Requirements to
revocation pointers out of a cert, ever. However, this is part of the
big value of short-lived certs, as it's what unlocks their
speed-increasing potential
On 04/09/14 12:52, Hubert Kario wrote:
It all depends on the exact definition of short-lived. If the definition
is basically the same as for OCSP responses or shorter, then yes, they
provide the same security as regular certs with hard fail for OCSP
querying/stapling.
The exact definition of
On 04/09/14 14:14, Hubert Kario wrote:
From what I heard (and my limited personal experience matches), is that
the vast majority of clients not only completely ignore failures in OCSP
retrieval (soft-fail) but completely lack any mechanism for revocation
checking
(be it OCSP or CRL).
I
On 04/09/14 19:20, Phillip Hallam-Baker wrote:
1) Any new scheme has to work equally well with legacy browsers and
enabled browsers.
Yes; I think short-lived certs meet that criterion.
2) Ditto for legacy servers and this is actually a harder problem as
upgrading a server can force a
On 05/09/14 00:06, Brian Smith wrote:
Precisely defining a short-lived certificate is a prerequisite for a
proper discussion of policy for short-lived certificates. It seems
likely to me that short-lived certificates will be defined as
certificates that would expire before the
On 04/09/14 19:32, fhw...@gmail.com wrote:
Could you (or anyone) elaborate a bit on the use cases where short
lived certs are desirable?
See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.
I'm also wondering
On 05/09/14 10:47, Rob Stradling wrote:
Unless the recently expired cert is found to be revoked, in which case
you'd show Secure Connection Failed I presume?
Yes :-)
but after that we switch to Secure Connection Failed. What do you think
of that idea?
If the false positive rate drops to
On 16/09/14 23:13, Richard Barnes wrote:
From a browser perspective, I don't care at all whether certificates
excused from containing revocation URLs if they're sufficiently short
lived.
From a technical perspective, that is true. However, if we have an
interest in making short-lived certs a
On 17/09/14 08:34, Kurt Roeckx wrote:
A browser could perfectly reject a certificate that doesn't comply with
the BR because the required OCSP URI is missing.
It could. If such browsers existed, I agree it would have a negative
effect on the likelihood of success of a short-lived certs plan.
On 25/09/14 13:43, Steve Roylance wrote:
You can encrypt communications if you have a public/private key pair
You can; although most often that's provided by the server in the model
of computing most prevalent on the web today.
You can digitally sign (with the full support of digital
On 25/09/14 13:45, Michał Purzyński wrote:
In order to leak the private cert you need to compromise the host.
Leaking the password is easier - you can compromise the web
application, the target server, the target company or the client’s
machine. You have a few more attack vectors with
On 25/09/14 13:53, Kurt Roeckx wrote:
On 2014-09-25 14:29, Gervase Markham wrote:
A question which occurred to me, and I thought I'd put before an
audience of the wise:
* What advantages, if any, do client certs have over number-sequence
widgets such as e.g. the HSBC Secure Key, used
On 25/09/14 17:53, Robin Alden wrote:
I can send out a million client certificates for negligible
cost.
Good point.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 25/09/14 22:33, Matt Palmer wrote:
* Client certs can be invisibly stolen if a machine is compromised
Well, the cert is quasi-public information, so it doesn't matter if they get
stolen, invisibly or otherwise. The private key, on the other hand...
grin But at any rate, just stick the
On 06/02/15 21:37, Kathleen Wilson wrote:
How do you all feel about the idea of one (or more) of the
representatives of the CAs in Mozilla's program also being a Peer of the
CA Certificates module?
I second Jeremy's point; it seems unwise to me for someone in a formal
relationship with a CA to
On 24/03/15 12:40, Peter Kurrasch wrote:
I'm confused because it sounds like you're advocating for the status
quo but I didn't think that was your position?
I am not in favour of non-consensual name constraints for CAs in
general. I think it would either be ineffective in improving security
(in
On 24/03/15 09:38, Florian Weimer wrote:
The intermediate certificate which prompted this discussion had C=EG,
which does not align well with a limitation to the Chinese market.
I'm not entirely sure what you are saying here. Are you saying you are
suprised not to see .eg in that list?
How
On 24/03/15 09:35, Florian Weimer wrote:
Sadly, name constraints do not work because they do not constrain the
Common Name field. The IETF PKIX WG explicitly rejected an erratum
which corrected this oversight.
NSS used to be different (before the mozilla::pkix rewrite), but it's
not
On 23/03/15 22:47, Richard Barnes wrote:
We propose to add name constraints to the CNNIC root in NSS to minimize the
impact of any future mis-issuance incidents.
I think it's worth noting that alternative options (both more and less
severe) would be considered, if people want to make a case
On 24/03/15 05:01, Peter Kurrasch wrote:
1) As a first step on the path to fairness, perhaps there can be
agreement that the goal of any name constraint policy should be the idea
that a single root does not get the whole internet. Maybe a whole CA
organization might, but a single root should
On 24/03/15 00:59, Peter Kurrasch wrote:
Is the proposal to limit CNNIC roots to only .cn domains or would
others be allowed?
That's a matter for discussion. We do have some data (thanks, Richard)
from CT and other places on the prevalence of CNNIC certificates in
those scans, broken down by
On 24/03/15 02:23, David E. Ross wrote:
What assurance is there that the mis-issued certificates were not
intentional.
All of the evidence we have seen does fit with the scenario as outlined
in the two blog posts. Of course, most of that evidence comes from CNNIC
(and MCS via CNNIC). But
On 24/03/15 09:03, Kurt Roeckx wrote:
So it's my understanding that they were only supposed to issue
certificates for their own domain(s). Why wasn't this enforced by using
a name constraint?
The implied answer to this question from statements by the CNNIC
representative is that their system
On 24/03/15 14:25, Florian Weimer wrote:
Technically, this is true. I just find it odd that the offending
certificate suggests a relationship with a non-Chinese market, while
at the same time, Richard's data only shows the top gTLDs and various
China-related TLDs.
This may be a limitation in
On 24/03/15 13:18, quanxunz...@gmail.com wrote:
As it is shown that, CNNIC doesn't have any proper audit policy for
issuing external subCA, and it is the first time they do so, can we
at least untrust any external subCA issued by CNNIC before their
updating policy gets reviewed?
You mean we
On 25/03/15 10:27, Florian Weimer wrote:
* The CNNIC CPS is incorrect, and they no longer run an
Entrust-sponsored sub-CA.
I believe this is the correct answer. Quoting Bruce Morton in this thread:
Please note that the intermediate certificate which Entrust issued to
CNNIC expired in 2012
On 25/03/15 17:45, Ryan Sleevi wrote:
That is, in a hypothetical world where E1 is pursued (for any CA), the CA
can simply backdate the certificate. They'd be non-compliant with the
Baseline Requirements, presumably, but that is somewhat how we got here in
the first place.
So purely on a
On 27/03/15 19:09, Peter Kurrasch wrote:
1) Mozilla could refuse to validate any intermediate cert which CNNIC
has issued to a subordinate CA. (Note: I'm not sure that's the
technically precise term here.) Basically, CNNIC may issue
intermediates for itself but those paths going outside their
On 30/03/15 16:34, Richard Barnes wrote:
Adding the intermediates would allow CNNIC to continue to issue end-entity
certificates, and not penalize site owners immediately (as Peter notes).
However, it would prevent the acceptance of other intermediates, since the
improper issuance of
On 31/03/15 02:34, Peter Gutmann wrote:
So this is now a convenient excuse to kick out CNNIC, after the initial
attempts to not let them in in the first place failed. I've always wondered,
what do people have against CNNIC and Turktrust in particular?
I haven't seen anyone in this thread
On 27/03/15 06:41, Man Ho (Certizen) wrote:
Yeah, if this device is designed to issue certificates automatically.
Why does it have this feature? The answer is obviously for traffic
monitoring. But then why Paloalto would develop such problematic feature
which violate security principle? If it
On 30/03/15 16:34, Richard Barnes wrote:
After some further thought on this issue, I would like to propose the
following course of action:
1. Remove the CNNIC root certificates
2. (possibly) Temporarily add the CNNIC intermediate certificates
After consideration, I want to record two
On 23/03/15 22:49, Jeremy Rowley wrote:
Although CT would not have prevented issuance, requiring CT for all
certificates would have detected the misissuance much sooner.
I'm not sure that's true. The intermediate itself would not count as a
misissuance. The Google cert the firewall created
On 24/03/15 21:12, Peter Kurrasch wrote:
As to who should be forced to constrain, this is controversial. I would
argue that everyone should be forced, but that has certain problems. One
can argue that only government-run and certain other CA's should be
forced but then we are put in the
On 22/03/15 23:18, Kathleen Wilson wrote:
I'm thinking we need to update our wiki page:
https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
Well, the current list is in the BRs, so we either need to update the
BRs, or we need to decide that we want to be more
On 26/03/15 13:18, Peter Kurrasch wrote:
So, how much work does Mozilla feel like doing?
You know my views; other Mozilla people will have to speak for
themselves. And then we'll have an argument to see whose view prevails
:-) However, this dialogue was very useful in exploring some of the
On 23/03/15 16:41, Robin Alden wrote:
That would be nice!
Wouldn't it? :-)
Of all email-based domain control validation we perform those email
addresses (on the same domain being applied for) are used as follows:
admin@33.9%
hostmaster@ 7.8%
webmaster@
Hi Matt,
On 01/04/15 23:44, Matt Palmer wrote:
I'd like to see discussion of what happens if things *don't* go according to
plan, though. The plan relies quite a bit on CNNIC's cooperation, both to
provide the list of existing certificates, as well as making (and abiding
by) the undertaking
On 02/04/15 02:42, Reed Loden wrote:
From
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
Indeed. It seems that Google have independently come to very similar
conclusions to us.
Gerv
___
On 01/04/15 22:41, Richard Barnes wrote:
That's certainly an option. I didn't want to prescribe a specific
mechanism in my initial proposal, since this seemed like an implementation
detail. In principle, just a list of issuer/serial pairs would be
sufficient to recognize bad certs, if CNNIC
On 02/04/15 19:33, Daniel Micay wrote:
Is there really a way we could notice this? Other than a leak from an
employee at CNNIC...
To be used, certs generally have to be public. Which means people can
find them. And compare them to lists.
We may end up coding the whitelist into Firefox, we may
On 02/04/15 09:49, c.le...@gmail.com wrote:
China has a enormous internet population and enormous number of
websites. Yes CNNIC acted like a dangerous kid. But you really think
making all Chinese unable to do any online transaction is the
solution we want to push?
Our plan will not have that
On 11/04/15 01:05, Brian Smith wrote:
If a US-based CA were in a similar situation, would we consider name
constraining them to *.com, *.org, *.net, *.us?
If it were a US government CA, we could certainly constrain to .gov and
.mil.
No, because that's not
much of a constraint. For people
On 24/04/15 08:17, Man Ho (Certizen) wrote:
The term transfer a root certificate is new to me. What are the
rationale of such transferal? Move from one location to another
location, or from one HSM to another HSM? Ownership of the CA had
changed from one organization to another organization?
On 29/04/15 17:23, Kathleen Wilson wrote:
I will appreciate your feedback on the email and the survey (use link
below).
All looks good to me. Although it's a shame Salesforce seems not to be
able to embed links.
Gerv
___
dev-security-policy mailing
On 05/05/15 21:54, Kathleen Wilson wrote:
EXAMPLE/DRAFT Survey Link:
https://community-mozillacaprogram.cs21.force.com/Communications/TakeSurvey?id=a04q004jpXoAAIcId=caId=none
LGTM.
Gerv
___
dev-security-policy mailing list
On 15/05/15 00:01, Ryan Sleevi wrote:
On Thu, May 14, 2015 9:02 am, David E. Ross wrote:
With cyberwarfare constantly discussed in the news, U.S. Congress, and
other venues, it appears to me that government CAs should indeed be
restricted to the TLDs of their respective jurisdictions.
On 14/05/15 17:02, David E. Ross wrote:
There is an ongoing dispute between the U.S. and China whether the
government in China is behind attacks on both government and commercial
computer systems in the U.S. This is NOT to question the
trustworthiness of the government of China but to give
Hi everyone,
The topic of name-constraining government CAs, probably to the TLD(s) of
their territory(ies), has come up numerous times. I'd like to try and
hash out, once and for all, whether we think this is actually a good
idea, so we can decide to work towards doing it, or decide actively not
On 17/05/15 23:28, Peter Bowen wrote:
I'll bite.
What if Mozilla puts a simple rule in place?
All CAs must either:
- Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
assessor who meets the requirements of BR 8.2 or
- Be named constrained
The result of that would be
On 17/05/15 02:12, Ryan Sleevi wrote:
I say this because knowing Gerv, and having participated with him on the
call, I suspect that in part this is motivated by
https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft
has suggested they'll require government CAs (definition not
On 17/05/15 00:45, Eric Mill wrote:
Governments are not subject to the same kind of leverage, accountability or
market forces that corporations are. The legal constraints they operate
under are different, your likelihood of prevailing in a legal action
against them is different (and highly
On 18/05/15 14:45, Gervase Markham wrote:
On 17/05/15 23:28, Peter Bowen wrote:
I'll bite.
What if Mozilla puts a simple rule in place?
All CAs must either:
- Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
assessor who meets the requirements of BR 8.2 or
- Be named
Before I reply, can I say that this level of informed and considered
debate is _exactly_ what I was looking for? Thanks to everyone who has
participated so far.
On 15/05/15 19:49, Ryan Sleevi wrote:
- By introducing a demarcation of power/privilege by government or not
(which still suffers from
On 19/05/15 02:15, Matt Palmer wrote:
I disagree that we, the browsers and standards bodies of the Internet have
very different leverage. In either case, if a CA misbehaves, their root
certs can be pulled from the trust store (or otherwise neutered). That
doesn't change because the CA is run
On 18/05/15 17:39, Kurt Roeckx wrote:
On the other hand, if it covers the whole country, they can abuse
it for domains in that country, but not for other domains. I'm
not sure why you would find it acceptable that they can abuse it
in their own country.
Some countries, AIUI, do not have an
On 09/04/15 21:12, yuhongbao_...@hotmail.com wrote:
What about Mozilla's own aus3.mozilla.org certificate for which the SHA-1
intermediate was pinned?
I'm afraid I don't understand the question, or how it relates to the CA
Communication. Can you clarify?
Gerv
On 14/04/15 00:15, Peter Kurrasch wrote:
Let's use an example. Suppose CNNIC issues a cert for
whitehouse[dot]gov
presumably without permission ;-)...
and let's further suppose that CNNIC includes this
cert in the CT data since they have agreed to do that. What happens
next?
If no-one
On 14/04/15 01:19, Matt Palmer wrote:
I'm not a fan of browser-imposed name constraints on CAs, at a philosophical
level. An important principle of the Mozilla root program, IMO, is that it
works for the public good (insofar as the public is represented by users
of Mozilla products). A name
On 05/04/15 13:12, Erwann Abalea wrote:
It would be very helpful if you could provide some evidence of this.
Qihoo 360 is a browser member of the CABForum, the product treats
certificate validation errors differently than other browsers, in a
non secure way. But having additional certificates
On 03/04/15 01:46, Matt Palmer wrote:
On the other hand, CNNIC's blog post suggests that they haven't. There's
some serious cognitive dissonance going on here.
Just to close this loop: CNNIC have now supplied us with a ZIP file of
all their currently-valid issued certificates.
Given that
On 04/04/15 04:20, Eugene wrote:
According to the CA Baseline Requirements section 8.2.1, The CA
SHALL develop, implement, enforce, and **annually update** a
Certificate Policy and/or Certification Practice Statement that
describes in detail how the CA implements the latest version of these
On 02/04/15 12:42, Sebastian Wiesinger wrote:
the plan would be to continue allowing current certificats (perhaps
with some sort of whitelist) while not accepting new certificates.
Could you ask Google to share their whitelist?
Until they announced, we were not aware that Google would be
On 17/06/15 22:50, Brian Smith wrote:
By small scope, I'm referring to CAs who limit their scope to a certain
geographical region, language, or type of institution.
I'm not sure how that neuters my objection. CAs who do more than DV will
need to have local infrastructure in place for identity
On 30/05/15 20:20, Brian Smith wrote:
By the way, what is Firefox's market share in China and other places that
commonly use CNNIC-issued certificates? My understanding is that it is
close to 0%. That's why it was relatively easy to remove them in the first
place. It also means that there's no
On 28/05/15 23:07, Richard Barnes wrote:
I agree that if CNNIC is to reapply, it should be with a new root. It
creates a clean break between the past and the future. It clarifies that
the new audits that are required apply to the new thing, and that the old
thing is dead. It's marginally
On 06/06/15 02:12, Brian Smith wrote:
Richard Barnes rbar...@mozilla.com wrote:
Small CAs are a bad risk/reward trade-off.
Why do CAs with small scope even get added to Mozilla's root program in the
first place? Why not just say your scope is too limited to be worthwhile
for us to
On 28/05/15 00:32, Peter Kurrasch wrote:
I think this is the crux of the problem: how do we want to treat all
the existing certs which chain to this root?
That's not the only problem. Requiring CNNIC to apply with a new root
would also require them to go through the inclusion process again in
On 31/05/15 23:43, Ryan Sleevi wrote:
I agree, this is the strongest argument against government CAs presented
in this thread, and I wish this, rather than the musings of secret courts
and maybe impossibles, was the core of your argument.
These arguments apply not just to government CAs
On 16/06/15 02:54, Peter Bowen wrote:
First, the policy says All disclosure MUST be made freely available and
without additional requirements, including, but not limited to,
registration, legal agreements, or restrictions on redistribution of the
certificates in whole or in part.
If I read
On 26/05/15 22:26, Kathleen Wilson wrote:
But this raises the question of whether their re-application can be for
the same (currently-included) root certificates, or if it has to be for
a new root certificate. In other words, should we consider taking the
stance that we will require a new root
On 06/07/15 15:34, Ben Wilson wrote:
=P7-TA-2014-0282 language=ENreference=P7-TA-2014-0282, I was asked (by
someone in the audience and not by anyone specifically representing EU
governments) to relay a message that some European supervisory bodies would
like browsers and OS providers to
On 19/05/15 12:14, Matt Palmer wrote:
The *leverage* that can be applied to any particular CA doesn't change based
on who operates it. Regardless of the operator, the only leverage we have
is removal of the CA's root certs from the trust store (or otherwise
neutering them). That certain CAs
On 19/05/15 13:14, Kurt Roeckx wrote:
On 2015-05-14 17:25, Gervase Markham wrote:
CAs currently in Mozilla's program which may fit one or more definitions
of government CA are:
It might be a little out of scope of your question, but maybe we should
agree on what we think the (government
On 21/05/15 13:56, Peter Kurrasch wrote:
Returning to your original post, Gerv
Thank you :-)
So here is where the difference really lies between government and
commercial CAs: control. Governments and, therefore, government CAs
wield a level of control that commercial entities normally
Hi Percy,
On 24/05/15 06:19, percyal...@gmail.com wrote:
This is Percy from GreatFire.org. We have long advocated for the
revoking of CNNIC.
https://www.google.com/webhp?sourceid=chrome-instantion=1espv=2ie=UTF-8#q=site%3Agreatfire.org%20cnnic
If CNNIC were to re-included, CT MUST be
On 24/07/15 06:45, David E. Ross wrote:
In Certificate Manager, on the Servers tab, I see a number of
certificates that were apparently placed there to force distrust. Most
of them have expired. Are they still needed?
Yes, because the UI treatment of an expired certificate is different to
On 26/10/15 23:46, Richard Barnes wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1204656
I'm surprised it's taken LE as long as a month to review whether the
info-gathering document has been correctly transcribed...
Gerv
___
dev-security-policy
On 10/11/15 23:44, Ryan Sleevi wrote:
> If a CA has issued such a cert to an applicant that they didn't vet as
> being the authorized representative of the relevant national
> administrator, then that's arguably no different than issuing a cert to
> someone who isn't the authorized domain holder -
On 15/10/15 10:54, Rob Stradling wrote:
> Rick, your report [1] states that...
>
>"...the certificates never left Symantec's secure test labs or the
A charitable reading of this might be "the private keys never left...".
But yes, it might help to have more details on what exactly is being
On 14/10/15 01:15, Charles Reiss wrote:
> As of this writing, there appears to be a functional server at that
> www.icns.com.au which presents that (expired and revoked) cert and to which
> openssl s_client can successfully connect.
>
> Is this entry an error?
Thank you for doing this
1 - 100 of 866 matches
Mail list logo
